کاردینال بیگلز، اریک بی ایمان را بیش از چهار ساعت روی صندلی راحتی نشاند تا سرانجام این اعترافات را از او گرفت ...
اولین نگاه من به پیتون یک تصادف بود، و علاقه چندانی به چیزی که در آن زمان دیدم پیدا نکردم. اوایل سال 1997 بود و کتاب "برنامه نویسی پیتون" نوشته مارک لوتز از انتشارات
O'reilly به تازگی بیرون آمده بود. کتابهای
O'reilly به ندرت به در خانه من می رسند، که در آن مورد هم توسط یک فرد ذینفع درون سازمان طی یک فرآیند تصادفی که من تصمیم گرفته ام دیگر سعی در فهمیدن آن نکنم، از بین تازه های چاپ برای من فرستاده می شوند.
یکی از این کتابها "برنامه نویسی پیتون" بود. از آنجا که من زبان های رایانه ای را جمع آوری می کنم، این موضوع برایم جالب بود. من بیش از دوجین زبان همه منظوره بلدم، برای تفریح مفسر و مترجم های زیادی نوشته ام و شخصا تعدادی زبان های یک منظوره و فرمهای نشانه گذاری (
Markup ) مختلف طراحی کرده ام. تازه ترین پروژه ای که من در زمان نوشتن این مقاله به پایان رسانده ام، یک زبان یک منظوره به نام
SNG برای کار کردن روی تصاویر
PNG یا
Portable Network Graphics است. خوانندگان علاقمند می توانند صفحات خانگی
SNG را در آدرس
http://www.catb.org/~esr/sng مشاهده کنند. من همچنین چند نسخه پیاده سازی شده از چند زبان همه منظوره عجیب را در صفحه
Retrocomputing Museum خود به آدرس
http://www.catb.org/retro قرار داده ام.
من قبلا آنقدر درباره پیتون شنیده بودم که بدانم از آن چیزهایی است که امروزه به آنها زبانهای اسکریپت می گویند، یک زبان تفسیری با مدیریت داخلی (built-in ) حافظه و تسهیلاتی خوب برای فراخوانی و همکاری با دیگر برنامه ها. بنابراین در هنگام شروع پیتون یک سوال بالاتر از همه مسائل برای من مطرح بود: این زبان چه چیزی دارد که پرل ندارد؟
البته، پرل گوریل ۸۰۰ کیلویی زبان های اسکریپت امروزی است. این زبان تا حدی به لطف کتابخانه های یونیکس و اعلان های جامع خود و تا حدی به دلیل مجموعه بزرگ ماژول های به وجود آمده توسط جامعه برنامه نویسان پرل ، به نسبت زیادی جایگزین زبانهای اسکریپت انتخابی مدیران و ناظران سیستم ها شده است. این زبان، زبان CGI پنهان در پشت حدود ۸۵% محتوای "زنده" بر روی شبکه به شمار می رود. سازنده آن، Larry Wall ، به درستی یکی از مهمترین رهبران جامعه متن باز به شمار می رود و اغلب پس از Linus Torvalds و Richard Stallaman در مکان سوم جایگاه خدایان قرار می گیرد.
در آن زمان من پرل را برای تعدادی از پروژه های کوچک استفاده کرده بودم. من این زبان را بسیار قدرتمند یافتم گرچه به نظر من می رسید سینتکس و بعضی جنبه های دیگر این زبان می توانند تا حدی برای شخصی که به آن عادت نداشته باشد، خطرناک باشند. به نظر من می رسید که پیتون به عنوان یک زبان اسکریپت باید گام مهم دیگری بردارد، بنابراین درحال خواندن به دنبال چیزی می گشتم که به نظر برسد آن را از زبان پرل مجزا می کند.
من به سرعت مطالب غیرعادی اصلی ای که ممکن است در پیتون به نظر هر کسی برسد را مرور کردم: این واقعیت که فضای خالی (indentation ) در سینتکس این زبان بامعنی است؛ این زبان هیچ سنخیتی با ساختار آکولادی C و پرل ندارد، در عوض تغییرات در توگذاری (indentation ) محدودیت گروه های عبارات را از بین می برند؛ و مثل اکثر هکرها پس از فهمیدن این مطلب با بی علاقگی عقب کشیدم.
آنقدر از عمر من گذشته است که برای چند ماهی در دهه ۷۰ با FORTRAN برنامه نویسی کرده باشم. اکثر هکرهای این دوره چنین نیستند ولی به نظر می رسد فرهنگ ما به گونه ای ، خاطره ای دقیق وسنتی از اینکه آن زبان های قدیمی با محدوده ثابت چقدر عذاب آور بودند حفظ کرده باشد. "فرمت آزاد"، که درآن زمان برای توصیف حالت جدیدتر سینتکس token-oriented زبان های C و پاسکال استفاده می شد، تقریبا فراموش شده است؛ چندین دهه است تمامی زبان ها اینگونه طراحی شده اند، یا تقریبا تمام زبان ها. بسیار سخت است کسی را، پس از دیدن این ویژگی پیتون، به خاطر عکس العمل اولیه ای مانند اینکه به صورت غیرمنتظره در انبوهی از بی ادبی! دایناسور قدم گذاشته است سرزنش کرد.
این احساس من در آن زمان بود. من بدون علاقه چندانی از کنار بقیه توضیحات این زبان گذاشتم. من دلیل چندان دیگری برای توصیه پیتون پیدا نکردم به جز اینکه احتمالا سینتکس آن تا حدی شسته و رفته تر از پرل بود و امکانات موجود برای اجرای CGI های ابتدایی مانند دکمه ها و منوها بسیار خوب به نظر می رسید.
من کتاب را با این یادآوری ذهنی که باید زمانی یک پروژه کوچک با محوریت GUI انجام دهم، تا مطمئن شوم که واقعا این زبان را می فهمم، در قفسه گذاشتم. ولی باور نداشتم چیزی که دیده ام هرگز بتواند به طور موثر با پرل رقابت کند.
اتفاقات زیادی باعث شدند این یادآوری ذهنی ماه ها در فهرست اولویت های من در مکان آخر قرار بگیرد. بقیه سال ۱۹۹۷ برای من پر از اتفاقات بود، در کنار بقیه اتفاقات، این سالی بود که من نسخه اصلی "کلیسای اعظم و بازار" را نوشته و منتشر کردم. در عین حال من فرصت یافتم تا چندین برنامه پرل بنویسم، از جمله دو برنامه با حجم و پیچیدگی قابل توجه. یکی از آنها، keeper ، برنامه دستیاری است که همچنان برای بایگانی پرونده های ارسالی وارده در شرکت نرم افزاری Metalab به کار می رود. این برنامه تولیدکننده صفحات وبی است که شما در http://metalab.unc.edu/pub/Linux/!INDEX.html مشاهده می کنید. برنامه دیگر، anthologize ، با هدف تولید خودکار PostScript برای ششمین ویرایش لینوکس از آرشیو "چگونه ها" ی پروژه مستندسازی لینوکس استفاده شد. هر دوی این برنامه ها در Metalab موجود هستند.
نوشتن هر دوی این پروژه ها مرا بیشتر و بیشتر از پرل ناراضی کرد. به نظر می رسید پروژه های با اندازه بزرگتر یک نارضایتی ساده از پرل را تبدیل به مشکلات جدی و مداوم می نمایند. سینتکسی که در صد خط ابتدایی بسیار راضی کننده به نظر می رسید، با گذشت زمان تبدیل به توده ای از خارهای غیرقابل نفوذ می شد. "بیش از یک راه برای انجام کار" که حال و هوا و تاثیرگذاری خاصی به آن می بخشید، نگهداری یک استیل خاص در یک محدوده کد وسیعتر را به مقدار قابل توجهی مشکل می ساخت. و بسیاری قابلیت هایی که بعدا به منظور جوابگویی به نیاز برای کنترل پیچیدگی در برنامه های بزرگتر (اشیاء، lexical scoping ،use strict و ...) به پرل اضافه شده بودند حالتی شکننده و نه چندان دلچسب داشتند.
تمامی این مشکلات دست به دست یکدیگر داده بودند تا خواندن و درک حجم زیادی از کدهای پرل به عنوان یک کلیت را تنها پس از چند روز به صورت غیرمنطقی ای مشکل کنند. علاوه بر این، من دریافتم که روز به روز زمان بیشتری را به جای ور رفتن با برنامه خود، صرف ور رفتن با قابلیت های این زبان می کنم و بدتر از همه اینکه کد من زشت شده بود ، ... این مساله واقعی بود. برنامه های زشت مثل پل هایِ معلقِ زشت هستند، واژگون شدن آنها بسیار محتمل تر از انواع زیبای آنها است، زیرا نحوه ادراک انسان ها (به خصوص مهندس- انسانها) از زیبایی رابطه بسیار نزدیکی با قابلیت ما برای پردازش و فهم پیچیدگی دارد. زبانی که کار نوشتن کد باوقار و باشکوه را سخت کند در حقیقت نوشتن کد خوب را مشکل کرده است.
با وجود یک دو جین زبان که به آنها تسلط داشتم، من می توانستم به تمامی علامات مشهود یک طراحی زبان که به منتهای قابلیت خود رسیده است و چیز بیشتری برای عرضه ندارد پی ببرم. من فکر کردم "باید راه بهتری وجود داشته باشد" و شروع به گشتن به دنبال یک زبان اسکریپت باشکوه تر کردم.
موردی که من حتی به آن فکر نکردم بازگشت به C به عنوان یک زبان پیش فرض بود. دوره ای که انجام مدیریت حافظه در یک برنامه به صورت شخصی معنا داشت، به جز در بعضی زمینه ها مانند طراحی هسته سیستم عامل (kernel hacking ) ، برنامه نویسی علمی و گرافیک ۳ بعدی که در آنها شما نیاز دارید بیشترین سرعت و کنترل کامل بر روی استفاده از حافظه به منظور حداکثر استفاده از سخت افزار را داشته باشید، مدتهاست که گذشته است.
در اکثر موارد دیگر پذیرفتن بار اضافه debug کردن [ چندین اصطلاح را در این قسمت حذف کردم م.] و دیگر مشکلات از این دست در ماشین های امروزی دیوانگی است. بسیار عاقلانه تر است که چندین چرخه و چندین کیلوبایت حافظه برای نیازهای مدیر حافظه یک زبان اسکریپت فدا کنیم و در وقت گرانبهای انسان صرفه جویی کنیم. در حقیقت استفاده از این راهبرد (استراتژی) دقیقا همان چیزی است که باعث رشد انفجاری پرل از اوایل دهه ۹۰ شده است.
مدتی با Tcl ور رفتم تا متوجه شدم که در مقیاس های بالا حتی از پرل هم ضعیفتر عمل می کند. به عنوان یک برنامه نویس قدیمی LISP ، همچنین نگاهی به اشکال ( dialects ) مختلف رایج LISP و Scheme انداختم ولی همانگونه که از نظر تاریخی در مورد LISP معمول است، طراحی های هوشمندانه متعدد آن به دلیل عدم وجود یا ناقص بودن مستندات، دسترسی ناقص به امکانات POSIX/UNIX و یک جامعه کوچک و در عین حال بسیار پراکنده کاربران، بی استفاده شده بودند. پرطرفدار بودن پرل به هیچ عنوان یک تصادف نیست؛ اکثر رقبای آن یا برای پروژه های بزرگ بدتر از پرل هستند یا اصلا و ابدا به آن مفیدی که ساختار نظری برتر آنها انتظارش را ایجاد می کند نیستند.
نگاه دومی من به پیتون تقریبا همانقدر تصادفی بود که نگاه اول. در اکتبر ۱۹۹۷، یک سری سوالات در فهرست نامه های الکترونیک افراد استفاده کننده از fetchmail این موضوع را کاملا مشخص کرد که افراد برای ایجاد فایل های تنظیمات برنامه fetchmail دچار مشکلات فزاینده ای می شوند. این فایل دارای ساختاری ساده و کلاس به سبک فرمت آزاد یونیکس است ولی می تواند هنگامی که کاربر دارای چندین حساب از نوع POP3 و IMAP باشد، به شدت پیچیده شود. به عنوان نمونه، برای دیدن یک مثال ساده شده از برنامه من به لیست ۱ نگاه کنید.
Listing 1. fetchmail Configuration File
set postmaster ``esr ''
set daemon 300
poll imap.ccil.org with proto IMAP and options no dns
aka snark.thyrsus.com locke.ccil.org ccil.org
user esr there is esr here options fetchall dropstatus warnings 3600
poll imap.netaxs.com with proto IMAP
user "esr" there is esr here options dropstatus warnings 3600
skip imap.21cn.com with proto IMAP
user esr here is tranxww there options fetchall
skip pop.tems.com with proto POP3 :
user esr here is ed there options fetchall
skip mail.frequentis.com with proto IMAP :
user esr here is imaptest there with options fetchall
من تصمیم گرفتم برای حل مشکل از یک ویرایشگر تنظیمات با حالتی کاربر پسند ( End-User-Friendly ) به نام fetchmailconf استفاده کنم. هدف از طراحی fetchmail مشخص بود؛ پنهان کردن کامل سینتکس فایل کنترل در پشت ظاهر شیک و صحیح از نظر ارگونومی یک رابط گرافیکی کاربر ( GUI ) با کلیدهای انتخاب، منوهای کشویی و فرم های مختلف.
فکر پیاده کردن این برنامه با پرل چندان مرا ذوق زده نکرد. من کدهای GUI را در پرل دیده بودم که ترکیبی ناهمگون بود از پرل و Tcl که حتی از کد پرل خود برنامه هم زشت تر بود. در این لحظه بود که قولی را که ۶ ماه قبل داده بودم یادم آمد. این می توانست فرصتی برای کسب یک تجربه عملی با پیتون باشد.
البته این موضوع مجددا من را با بامعنی بودن فضای خالی در پیتون روبرو کرد. البته این بار تخته گاز پیش رفتم و مقداری کد برای انبوهی از عناصر GUI نوشتم. جدا ّ حیرت آور بود که تنها پس از ۲۰ دقیقه، استفاده پیتون از فضای سفید دیگر امر عجیبی به نظر نمی آمد. من همانقدر از فرورفتگی متن در پیتون استفاده می کردم که امکان داشت در C از آن استفاده کنم و این روش جواب هم می داد.
این اولین حیرت من بود. حیرت دومی ، حدود ۲ ساعت بعد (با احتساب زمان های توقفی که برای نگاه کردن به قابلیت های پیتون در کتاب Learning Python صرف شد) ، وقتی پیش آمد که متوجه شدم با همان سرعتی مشغول نوشتن برنامه های به دردبخور هستم که می توانم تایپ کنم. وقتی متوجه این موضوع شدم تقریبا مبهوت شدم. یکی از معیارهای مهم عملکرد در برنامه نویسی تعداد دفعاتی است که شما چیزی می نویسید که واقعا با درک شما از مساله همخوانی ندارد و ناچارید پس از فهمیدن این موضوع که چیزی که تایپ کرده اید، به زبان آنچه را شما فکر می کنید نمی گوید به عقب برگردید. یکی از معیارهای مهم طراحی مناسب زبان اینست که درصد چنین اشتباهاتی با تجربه پیدا کردن شخص در آن زبان با چه سرعتی کاهش می یابند.
هنگامی که شما با بیشترین سرعتی که قادرید تایپ کنید، برنامه به دردبخور می نویسید و اشتباهات شما در انتخاب مسیر تقریبا صفر است، این به آن معناست که شما در آن زبان به استادی رسیده اید. ولی این بی معنی بود، چون به زحمت یک روز از این موضوع گذشته بود و من هنوز مجبور بودم امکانات مربوط به زبان و کتابخانه ها را از روی کتاب نگاه کنم.
این اولین چیزی بود که به من فهماند من در پیتون با یک طراحی عالی سروکار دارم. اکثر زبانها آنقدر دارای تداخل و ضعف در طراحی خود هستند که شما قبل از اینکه ضریب اشتباهاتتان در آنها حتی نزدیک به صفر شود بسیاری از امکانات آنها را فرا گرفته اید. پیتون تنها زبان همه منظوره ای بود که من تا آن روز استفاده کرده بودم و این فرآیند را معکوس می کرد.
البته یادگیری مجموعه امکانات آن نیز چندان وقت گیر نبود. من یک برنامه fetchmailconf کارآ و قابل استفاده، به همراه GUI ، را در ۶ روز کاری نوشتم که از این ۶ روز احتمالا ۲ روز آن تماما صرف یادگیری خود پیتون شد. این موضوع نشان دهنده یک خاصیت مفید دیگر این زبان است: این زبان حالت اختصاری دارد، شما می توانید تمامی مجموعه امکانات آن (حداقل یک ایده فهرست وار از کتابخانه های آن) را در ذهن نگه دارید. C زبانی است که به اختصار معروف است. پرل در این زمینه شهرت خوبی ندارد. یکی از چیزهایی که عبارت معروف "بیش از یک راه برای انجام آن وجود دارد!" قربانی می کند توانایی مختصر بودن پرل است.
ولی هنوز رویایی ترین کشف من باقی مانده بود. طراحی من یک مشکل داشت: من قادر بودم به راحتی فایل های تنظیم را با استفاده از عملهای GUI کاربر تولید کنم ولی ویرایش آنها مشکل بزرگتری بود. یا بهتر است بگویم خواندن آنها به یک شکل قابل ویرایش کار مشکلی بود.
Parser به کار رفته برای سینتکس فایل تنظیماتfetchmail بسیار کاربر بود. این برنامه در حقیقت با استفاده از YACC و Lex ، دو ابزار کلاسیک یونیکس برای تولید کد parsing زبان در C ، نوشته شده بود. تصور من این بود که برای اینکه قادر به ویرایش فایلهای تنظیمات در fetchmail باشم ناچار به تکرار همان parser وقت گیر در پیتون خواهم بود. من برای انجام این کار بسیار دودل بودم، تا حدودی به دلیل حجم کار و تا حدودی هم به دلیل اینکه نمیدانستم از کجا باید مطمئن باشم که دو parser در دو زبان مختلف مثل یکدیگر عمل خواهند کرد. کار فوق العاده زیاد همخوان نگاه داشتن دو parse آخرین چیزی بود که ممکن بود من با تحول زبانها به آن نیاز داشته باشم.
این مشکل برای مدتی مرا متوقف کرد. بعد از این فکری به ذهنم رسید: من به fetchmailconf اجازه می دادم از parser خود استفاده کند. من یک گزینه –configdump به fetchmail اضافه کردم و نتیجه را در یک خروجی استاندارد با فرمت یک initializer پیتون تخلیه کردم. برای فایل بالایی، نتیجه تقریبا شبیه به لیست ۲ بود (برای صرفه جویی در فضا بعضی داده های غیرمرتبط با مثال حذف شده اند).
Listing 2. fetchmailrc
fetchmailrc = {
'poll_interval':300 ,
"logfile":None ,
"postmaster":"esr ",
'bouncemail':TRUE ,
"properties":None ,
'invisible':FALSE ,
'syslog':FALSE ,
# List of server entries begins here
'servers’:[
# Entry for site `imap.ccil.org' begins :
{
"pollname":"imap.ccil.org ",
'active':TRUE ,
"via":None ,
"protocol":"IMAP ",
'port':0 ,
'timeout':300 ,
'dns':FALSE ,
"aka":["snark.thyrsus.com", "locke.ccil.org", "ccil.org " ]
'users’: [
{
"remote":"esr ",
"password":"Malvern ",
'localnames':["esr " ] ,
'fetchall':TRUE ,
'keep':FALSE ,
'flush':FALSE ,
"mda":None ,
'limit':0 ,
'warnings':3600 ,
}
, [
}
,
# Entry for site `imap.netaxs.com' begins :
{
"pollname":"imap.netaxs.com ",
'active':TRUE ,
"via":None ,
"protocol":"IMAP ",
'port':0 ,
'timeout':300 ,
'dns':TRUE ,
"aka":None ,
'users ': [
{
"remote":"esr ",
"password":"d0wnthere ",
'localnames':["esr " ] ,
'fetchall':FALSE ,
'keep':FALSE ,
'flush':FALSE ,
"mda":None ,
'limit':0 ,
'warnings':3600 ,
}
, [
}
,
# Entry for site `imap.21cn.com' begins :
{
"pollname":"imap.21cn.com ",
'active':FALSE ,
"via":None ,
"protocol":"IMAP ",
'port':0 ,
'timeout':300 ,
'dns':TRUE ,
"aka":None ,
'users ': [
{
"remote":"tranxww ",
"password":None ,
'localnames':["esr " ] ,
'fetchall':TRUE ,
'keep':FALSE ,
'flush':FALSE ,
"mda":None ,
'limit':0 ,
'warnings':3600 ,
}
, [
}
,
# Entry for site `pop.tems.com' begins :
{
"pollname":"pop.tems.com ",
'active':FALSE ,
"via":None ,
"protocol":"POP3 ",
'port':0 ,
'timeout':300 ,
'dns':TRUE ,
'uidl':FALSE ,
"aka":None ,
'users ': [
{
"remote":"ed ",
"password":None ,
'localnames':["esr " ] ,
'fetchall':TRUE ,
'keep':FALSE ,
'flush':FALSE ,
"mda":None ,
'limit':0 ,
'warnings':3600 ,
}
, [
}
,
# Entry for site `mail.frequentis.com' begins :
{
"pollname":"mail.frequentis.com ",
'active':FALSE ,
"via":None ,
"protocol":"IMAP ",
'port':0 ,
'timeout':300 ,
'dns':TRUE ,
"aka":None ,
'users ': ]
{
"remote":"imaptest ",
"password":None ,
'localnames':["esr " ] ,
'fetchall':TRUE ,
'keep':FALSE ,
'flush':FALSE ,
"mda":None ,
'limit':0 ,
'warnings':3600 ,
}
, ]
}
]
}
پیتون سپس قادربود خروجی fetchmail--configdump را ارزیابی کند و سپس تنظیمات را به صورت مقدار متغیر "fetchmail " ارائه کند.
حتی این هم آخرین حرکت رقص من نبود. چیزی که من می خواستم صرفا این نبود که fetchmail تنظیمات فعلی خود را داشته باشد بلکه می خواستم آن را تبدیل به یک ساختار درختی از اشیا زنده (live objects ) کنم. احتمالا در این درخت سه نوع شی وجود داشت: تنظیمات ( که شیء واقع در بالاترین مرتبه و نشان دهنده کل تنظیمات بود)؛ سایت (نشان دهنده یکی از سایتهایی که باید به رای گذاشته می شد.) و کاربر ( نشان دهنده داده های کاربران که به سایت متصل می شود). فایل های مثال پنج شیء از نوع سایت که به هر کدام یک شیء از نوع کاربر متصل شده است را نشان می دهد.
تا اینجا من سه شیء کلاس را طراحی کرده و نوشته بودم (این همان چیزی بود که چهار روز از وقت من را گرفت که اکثر آن هم صرف چیدن درست و مناسب کنترلهای صفحه شد). هر یک از این کلاسها یک متد داشت که باعث می شد برای ویرایش داده های آن instance خاص یک صفحه GUI باز شود. تنها مشکل باقیمانده من یافتن روشی برای تبدیل اشیاء مرده این برنامه initializer پیتون به اشیاء زنده بود.
چیزی که به نظر من رسید نوشتن کدی بود که به وضوح راجع به ساختار هر سه کلاس بداند و از این دانش برای پلکیدن در initializer و ایجاد اشیایی که پاسخگوی نیازها باشند استفاده کند ولی این ایده را رد کردم زیرا اعضای این کلاس جدید احتمالا با اضافه شدن امکانات جدید به تنظیمات زیاد می شدند. اگر من کد ایجاد اشیا را با این روش مشهود می نوشتم، احتمال زیادی وجود داشت که کد حالت شکننده پیدا کند و با تغییر تعریفهای کلاس یا ساختار initializer از حالت به روز خارج شود.
چیزی که من واقعا به دنبالش بودم کدی بود که شکل و اعضای initializer را تجزیه و تحلیل کند، از تعریفهای کلاس برای پرس و جو درباره اعضای آن کلاس استفاده کند و سپس خودش را با این دو مجموعه هماهنگ کند.
به این گونه چیزها در اصطلاح هک کردن metaclass گفته می شود و در حالت عمومی چیزی به ترسناکی جادوی سیاه به شمار می روند. اکثر زبانهای برنامه نویسی شیءگرا مطلقا از این قابلیت پشتیبانی نمی کنند و در آنهایی که این کار را می کنند (که پرل هم یکی از آنهاست)، این موضوع امری پیچیده و ظریف و شکننده است. تا همان زمان من از ضریب بسیار پایین اشکال سازی پیتون متعجب شده بودم ولی این یک آزمایش واقعی بود. برای اینکه این زبان را مجبور به انجام چنین کاری کنم چقدر باید با آن کشتی می گرفتم؟ با استفاده از تجربیات قبلی می دانستم که ، حتی با این فرض که من ببرم، این می تواند تجربه دردناکی باشد ولی روی کتاب شیرجه رفتم و شروع به مطالعه امکانات metaclass پیتون کردم. تابع به دست آمده در لیست ۳ نشان داده شده است و کدی که فراخوانی می کند در لیست ۴ آمده است.
Listing 3. Metaclass Function
def copy_instance(toclass, fromdict) :
# Initialize a class object of given type from a conformant dictionary .
class_sig = toclass.__dict__.keys(); class_sig.sort ()
dict_keys = fromdict.keys(); dict_keys.sort ()
common = intersect(class_sig, dict_keys)
if 'typemap' in class_sig :
class_sig.remove('typemap ' )
if tuple(class_sig) != tuple(dict_keys) :
print "Conformability error "
# print "Class signature: " + `class_sig `
# print "Dictionary keys: " + `dict_keys `
print "Not matched in class signature: " + `setdiff(class_sig, common) `
print "Not matched in dictionary keys: " + `setdiff(dict_keys, common) `
sys.exit(1)
else :
for x in dict_keys :
setattr(toclass, x, fromdict[x])
Listing 4. Code that Calls Metaclass Function
# The tricky part--initializing objects from the
# configuration global
# `Configuration' is the top level of the object
# tree we're going to mung
Configuration = Controls ()
copy_instance(Configuration, configuration)
Configuration.servers = [];
for server in configuration[`servers ' ] :
Newsite = Server ()
copy_instance(Newsite, server)
Configuration.servers.append(Newsite)
Newsite.users = [];
for user in server['users ' ] :
Newuser = User ()
copy_instance(Newuser, user)
Newsite.users.append(Newuser)
برای جادوی سیاه چندان بد به نظر نمی رسد، اینطور نیست ؟ سی و دو خط با احتساب توضیحات. فقط با توجه به چیزهایی که من درباره ساختار کلاسها گفتم، حتی کد فراخوان نیز قابل خواندن است. ولی اندازه این کد موضوع شوکه کننده نیست. خودتان را کنترل کنید: نوشتن این کد تنها ۹۰ دقیقه وقت گرفت و در اولین باری که من آن را اجرا کردم به خوبی کار کرد.
تنها گفتن این که من حیرت زده شده بودم می تواند کم لطفی باشد. درست و به خوبی کار کردن پیاده سازی حتی ساده ترین تکنیکها در اولین بار همانگونه که انتظار می رفته می تواند امری قابل توجه باشد؛ ولی اولین هک کردن metaclass من تنها پس از ۶ روز از یک شروع بی مقدمه؟ حتی اگر به اغراق بگوییم که من یک هکر با استعداد هستم این یک موفقیت بزرگ برای پیتون در زمینه شفافیت و شکوه و عظمت طراحی است.
تقریبا هیچ راهی وجود نداشت که من بتوانم با وجود تجربه بسیار زیادترم در پرل عمل مشابهی را با استفاده از آن انجام دهم. در این زمان بود که احساس کردم که احتمالا پرل را ترک خواهم کرد.
این رویایی ترین لحظه من در پیتون بود. ولی حالا که همه اینها تمام شده باید بگویم تمام اینها یک هک هوشمندانه بود. مفید بودن یک زبان برنامه نویسی در بلند مدت بستگی به پشتیبانی آنها از هک های هوشمندانه ندارد بلکه به چند و چون پشتیبانی آن از امور روزمره برنامه نویسی مرتبط است. کار روزمره برنامه نویسی اکثرا به جای نوشتن برنامه های جدید، از خواندن و تغییر دادن برنامه های موجود تشکیل می شود.
مساله تکان دهنده اینجاست: هفته ها و ماه ها پس از نوشتن fetchmailconf ، من هنوز قادر بودم کد آن را بخوانم و بدون هیچ تلاش فکری جدی ای متوجه بشوم که چکار می کند و دلیل واقعی این موضوع که من دیگر برای هیچ چیزی جز پروژه های کوچک از پرل استفاده نمی کنم این است که این موضوع هرگز در مورد پرل صادق نبود. من حتی از تصور این موضوع که زمانی ناچار شوم keeper یا anthologize را تغییر دهم به وحشت می افتم در حالیکه برای انجام چنین کاری در مورد fetchmailconf ککم هم نمی گزد.
پرل همچنان کاربردهای خود را دارد. برای پروژه های کوچک (۱۰۰ خط یا کمتر) که شامل مقدار زیادی جور کردن الگوی متن است، من احتمالا بیشتر از یک راه حل با استفاده از پرل استقبال می کنم تا پیتون. برای دیدن چندین مثال خوب، برنامه های timeseries و growplot را در فهرست توزیع fetchmail مشاهده کنید. در حقیقت، این ها تا حد زیادی شبیه کاری هستند که پرل در نقش اصلی خود، قبل از اینکه دارای توابع و دسترسی مستقیم به API سیستم عامل باشد، به عنوان نوعی ترکیب awk/sed/grep/sh انجام می داد. برای هر چیز بزرگتر یا پیچیده تر، من عادت کرده ام که ارزشهای لطیف پیتون را ترجیح بدهم و فکر کنم شما نیز همین کار را انجام بدهید.
عضو شوید
عضویت سریع
آمار مطالب
آمار بازدید
